A number of advantageous results can be achieved with modern electronic components arranged in a variety of different system and network configurations. Operations directed at achieving the advantageous results often involve a significant amount of data communications between the electronic components. However, communications bandwidth in conventional electronic component systems and networks is usually limited by the processing capabilities of the electronic systems, local area network (LAN) characteristics and wide area network (WAN) characteristics. For example, WAN bandwidth can be relatively expensive and unpredictable, which can lead to slower response times. Some traditional attempts at addressing bandwidth limitation concerns involve compression of information included in a communication packet. However, traditional attempts at conserving bandwidth by compressing data can include complex compression history dependencies and maintaining synchronization between the compression and decompression points can be problematic.
Generally, compression of information included in communication packets works by having a compression engine at one end of the data link and a decompression engine at the other end. Data compression algorithms typically search for data string patterns within an input data packet stream, perform a mathematical pattern analysis, and replace portions of the data strings with encoded tokens of shorter length in a compressed output data packet stream. For example, data compression algorithms often search for a string in the input data that matches a previous data string and create an encoded token that consists of a pointer to the previous data string. The encoded tokens are utilized to replace the redundant strings in the input data packet stream. Stateless data compression and stateful data compression are two primary types of traditional data compression algorithms that utilized encoded token replacement.
In stateless data compression, the compression history is unique to each data packet and not maintained across different data packets. Stateless data compression is a relatively reliable compression technique because compression history synchronicity is maintained within each packet between compression and decompression points. However, because the compression history is reset after every packet, a higher compression ratio is often more difficult to achieve. For example, maintaining one generic compression history for all received packets without knowing the type of packet and compressing them can lead to poor compression ratios, including situations where compression inflates encrypted packets.
Stateful data compression is when compression history information is maintained across packets. By maintaining compression history across data packets, more data for utilization in creating a compression history is available. For example, GZIP compression history accumulated across multiple packets provides significantly more opportunity for “filling” traditional 32 Kbyte buffers and achieving a superior compression ratio compared to GZIP compression of each 1.5 K byte packet individually. However, both the compression and the decompression history need to be synchronized across packets for stateful data compression communication to operate properly.
In order for data packets to decompress correctly, the data packets have to be decompressed in the same order they were compressed. Consequently, if data packets that are incorporated into the compression history on the compression side are not delivered to the decompression side, the decompression engine decompresses the data packets incorrectly. For example, data packets 1, 2, and 3 can enter a compression engine in that order, and the compression engine can use the data in data packets 1 and 2 to compress data packet 3. If data packet 3 is decompressed before data packet 2, an incorrect decompression for data packet 3 can occur. Furthermore, subsequent data packets after data packet 3 that are also dependent on the dropped packet for decompression can result in a series of incorrectly decompressed packets.
Maintaining synchronous compression and decompression histories across data packets when an inter-data packet dependency is created can be difficult. A number of different situations can result in an upstream device compressing data and updating the upstream device's compression history without a corresponding update in the decompression history. In a situation in which the compressed data never reaches the downstream device, such as a packet is dropped or reordered during communication, the downstream device's decompression history becomes out of sync with the upstream device's compression history. In some situations, a deliberate decision not to send the compressed data is made after the data is compressed. When compressing data actually inflates the number of bits in a packet, a decision can be made to send the raw data instead of the compressed data, but since the data was compressed initially corresponding information is entered in the compression history. However, the downstream device does not make a corresponding update to the decompression history because the downstream device receives the sent raw data and not compressed data.
The sequential nature of communications tends to exacerbate the impact of compression history synchronization problems. Since the communications packets are usually a part of a communication packet stream, the downstream device can generate a series of incorrectly decompressed packets. Traditional attempts at addressing compression history synchronization problems typically consume considerable bandwidth. For example, some conventional approaches directed at synchronization resolution involve dedicated communications or handshaking that tie up or “consume” considerable bandwidth. Tying up limited bandwidth usually reduces perceived communication network performance and can adversely impact implementation of applications over a network.